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Abstract 

Automatic  generation  of  state  invariants,  properties 
that  hold  in  every  reachable  state  of  a  state  machine 
model,  can  be  valuable  in  software  development.  Not 
only  can  such  invariants  be  presented  to  system  users 
for  validation,  in  addition,  they  can  be  used  as  auxil¬ 
iary  assertions  in  proving  other  invariants.  This  paper 
describes  an  algorithm  for  the  automatic  generation  of 
state  invariants  that,  in  contrast  to  most  other  such  al¬ 
gorithms,  which  operate  on  programs,  derives  invariants 
from  requirements  specifications.  Generating  invariants 
from  requirements  specifications  rather  than  programs 
has  two  advantages:  1)  because  requirements  specifica¬ 
tions,  unlike  programs,  are  at  a  high  level  of  abstraction, 
generation  of  and  analysis  using  such  invariants  is  eas¬ 
ier,  and  2)  using  invariants  to  detect  errors  during  the 
requirements  phase  is  considerably  more  cost-effective 
than  using  invariants  later  in  software  development.  To 
illustrate  the  algorithm,  we  use  it  to  generate  state  in¬ 
variants  from  requirements  specifications  of  an  automo¬ 
bile  cruise  control  system  and  a  simple  control  system 
for  a  nuclear  plant.  The  invariants  are  derived  from 
specifications  expressed  in  the  SCR  (Software  Cost  Re¬ 
duction)  tabular  notation. 

Keywords — requirements,  specification,  formal  meth¬ 
ods,  invariants,  verification,  validation,  software  tools 

1  Introduction 

Given  the  high  frequency  of  defects  in  software  require¬ 
ments  specifications,  the  high  cost  of  correcting  them 
late  in  software  development,  and  the  serious  accidents 
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such  defects  may  cause,  techniques  for  the  early  detec¬ 
tion  and  removal  of  defects  from  software  requirements 
specifications  are  crucial.  One  formal  method  that  is 
designed  to  detect  and  correct  errors  during  the  require¬ 
ments  phase  of  software  development  is  the  SCR  (Soft¬ 
ware  Cost  Reduction)  method.  Originally  formulated 
to  document  the  requirements  of  the  Operational  Flight 
Program  (OFP)  for  the  U.S.  Navy’s  A-7  aircraft  [19], 
the  SCR  method  has  been  used  by  many  organizations 
in  industry  (e.g.,  Bell  Laboratories,  Grumman,  Ontario 
Hydro,  and  Lockheed)  to  specify  the  requirements  of 
practical  systems.  The  largest  application  of  SCR  to 
date  occurred  in  1993-94  when  engineers  at  Lockheed 
used  a  version  of  SCR  to  document  the  complete  re¬ 
quirements  of  Lockheed’s  C-130J  OFP  [12],  a  program 
containing  more  than  230K  lines  of  Ada  code. 

Introduced  in  1995,  the  SCR  toolset  [16,  17,  18]  is 
an  integrated  suite  of  tools  supporting  the  SCR  re¬ 
quirements  method.  Each  tool  in  the  suite  detects  a 
special  class  of  errors.  For  example,  the  specification 
editor  helps  the  user  detect  ambiguous  requirements; 
the  consistency  checker  automatically  detects  violations 
of  application-independent  properties,  such  as  type  er¬ 
rors  and  missing  cases;  the  simulator  helps  the  user  de¬ 
tect  cases  in  which  the  specification  fails  to  satisfy  the 
specifier’s  intent,  and  a  newly  integrated  model  checker 
SPIN  [21]  detects  violations  of  application-specific  prop¬ 
erties,  such  as  safety  properties  [6].  Recently,  NRL  ap¬ 
plied  the  SCR  tools  to  a  sizable  contractor-produced  re¬ 
quirements  specification  of  the  Weapons  Control  Panel 
(WCP)  for  a  safety-critical  U.S.  military  system  [15]. 
The  tools  uncovered  numerous  errors  in  the  contractor 
specification,  including  a  safety  violation.  This  viola¬ 
tion,  which  could  lead  to  a  serious  malfunction  of  the 
weapons  system,  was  detected  by  model  checking. 

To  specify  the  required  system  behavior,  users  of  the 
SCR  method  may  adopt  a  dual  language  approach  [29]. 
In  this  approach,  two  different  specifications  are  de¬ 
veloped,  one  operational  and  the  other  property-based. 
The  operational  (or  model-based )  specification  describes 
how  the  system  operates,  while  the  property-based  spec- 
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ification  describes  the  required  system  properties.  An 
operational  specification  may  represent  the  system  as  a 
state  machine,  whereas  a  property-based  specification 
usually  expresses  properties  as  logic  formulas.  In  the 
SCR  requirements  method,  the  operational  specifica¬ 
tion  is  expressed  in  tables  and  the  system  properties 
as  first-order  logic  formulas.  Examples  of  the  dual  lan¬ 
guage  approach  in  SCR  specifications  include  the  A- 7 
requirements  document  [19,  20],  which,  in  addition  to 
the  tabular  operational  specification,  contains  proper¬ 
ties  of  the  system  modes,  and  Kirby’s  cruise  control 
specification  [23],  which  contains  both  a  tabular  speci¬ 
fication  of  the  required  system  operations  and  a  list  of 
required  system  properties. 

The  dual  language  approach  is  useful  because  each 
specification  style  has  advantages:  operational  speci¬ 
fications  are  less  likely  to  omit  required  behavior  and 
are  often  executable,  whereas  property-based  specifi¬ 
cations  are  concise,  abstract,  and  minimize  implemen¬ 
tation  bias.  Another  advantage  of  the  dual  language 
approach  is  that  detecting  inconsistencies  between  two 
different  specifications  of  the  same  behavior  is  an  ef¬ 
fective  technique  for  debugging  both  the  statements  of 
the  required  properties  and  the  operational  specifica¬ 
tion.  For  example,  when  Dill  and  his  colleagues  used 
model  checking  to  analyze  a  hardware  design  for  sev¬ 
eral  properties  of  interest,  they  detected  errors  both  in 
the  design  and  in  the  stated  properties  [11]. 

One  formal  technique  useful  in  conjunction  with  the 
dual-language  approach  is  automatic  invariant  genera¬ 
tion.  This  technique  automatically  generates  state  in¬ 
variants,  properties  that  hold  in  every  reachable  state  of 
a  state  machine  model,  from  the  operational  specifica¬ 
tion.  Such  state  invariants  can  be  presented  to  system 
users  for  validation  or,  alternately,  can  be  used  as  aux¬ 
iliary  invariants  in  proving  additional  properties  from 
the  requirements  specification,  such  as  the  properties 
included  in  the  property-based  specification. 

This  paper  introduces  an  efficient,  automatable  al¬ 
gorithm  for  generating  state  invariants.  In  contrast 
to  most  other  such  algorithms,  which  operate  on  pro¬ 
grams,  our  algorithm  derives  invariants  from  require¬ 
ments  specifications.  Generating  invariants  from  re¬ 
quirements  specifications  has  two  major  advantages:  1) 
requirements  specifications,  unlike  programs,  are  at  a 
high  level  of  abstraction,  and  hence  generation  of  and 
analysis  using  such  invariants  is  easier,  and  2)  using  in¬ 
variants  to  detect  errors  during  the  requirements  phase 
is  considerably  more  cost-effective  than  using  invariants 
later  in  software  development. 

Our  algorithm,  which  extends  the  methods  described 
in  [3,  4],  generates  invariants  from  specifications  ex¬ 
pressed  in  the  SCR  tabular  notation.  The  invariants 
are  computed  by  combining  information  from  a  table 
taken  from  an  SCR  specification  and  various  other  facts, 


such  as  environmental  assumptions.  To  illustrate  the  al¬ 
gorithm,  we  show  how  special  invariants  called  “mode 
invariants”  can  be  derived  from  a  mode  transition  ta¬ 
ble,  a  type  of  table  appearing  in  SCR  specifications. 
Next,  we  obtain  invariants  from  two  other  types  of  ta¬ 
bles,  both  extracted  from  the  same  SCR  specification. 
To  demonstrate  the  utility  of  our  approach,  we  use  these 
invariants  as  auxiliary  invariants  in  proving  two  prop¬ 
erties  of  the  specification.  These  properties  were  previ¬ 
ously  proved  using  model  checking.  Finally,  we  present 
a  more  formal  description  of  a  generalized  version  of 
our  algorithm.  This  generalized  version  may  be  used  to 
extract  invariants  from  other  state-based  specifications, 
such  as  specifications  in  TLA  (Temporal  Logic  of  Ac¬ 
tions)  [24]  and  specifications  for  STeP  (Stanford  Tem¬ 
poral  Prover)  [27].  The  Appendix  presents  the  proof 
of  the  generalized  version  of  the  algorithm.  We  have 
formally  proved  the  correctness  of  the  generalized  algo¬ 
rithm  using  the  PVS  prover  [10,  30]. 

2  SCR  Requirements  Model 

An  SCR  requirements  specification  describes  a  nonde- 
terministic  environment  and  the  required  system  behav¬ 
ior  (usually  deterministic)  [17].  Monitored  (also  called 
input)  variables  and  controlled  (also  called  output)  vari¬ 
ables,  which  represent  the  respective  quantities  the  sys¬ 
tem  monitors  and  controls,  model  the  system  environ¬ 
ment.  The  environment  nondeterministically  generates 
a  sequence  of  input  events,  where  each  input  event  is  a 
single  change  in  some  monitored  variable.  Each  input 
event  may  cause  the  system  to  change  one  or  more  of 
the  controlled  variables. 

In  SCR,  NAT  and  REQ,  two  relations  of  the  Four 
Variable  Model  [32],  describe  the  required  system  be¬ 
havior.  NAT  describes  physical  constraints  on  the  en¬ 
vironment;  REQ  describes  the  relation  between  moni¬ 
tored  and  controlled  variables  that  the  system  must  en¬ 
force.  To  specify  REQ  concisely,  SCR  specifications  use 
two  types  of  auxiliary  variables:  mode  classes,  whose 
values  are  modes,  and  terms.  Both  mode  classes  and 
terms  may  be  used  to  capture  historical  information. 

More  formally,  an  SCR  system  E  is  represented  as 
a  state  machine  E  =  (S,  So,  Em ,  T),  where  S  is  the  set 
of  states,  So  C  S'  is  the  initial  state  set,  Em  is  the  set 
of  input  events,  and  the  transform  T  maps  each  input 
event  and  old  state  to  a  new  state  [17].  A  simplifying 
assumption,  called  the  One  Input  Assumption,  states 
that  one  input  event  occurs  at  each  state  transition. 
The  transform  T  is  the  composition  of  smaller  func¬ 
tions,  called  table  functions,  derived  from  the  tables  in 
an  SCR  requirements  specification.  (Alternatively,  the 
transform  can  be  expressed  in  relational  form — see  Sec¬ 
tion  6.)  Each  table  defines  a  term,  a  mode  class,  or  a 
controlled  variable. 


The  SCR  requirements  model  includes  a  set  RF  = 
{?’!,  r2,  . . . ,  ?•„}  containing  the  names  of  all  state  vari¬ 
ables  in  a  given  specification  and  a  function  TY  which 
maps  each  variable  to  its  type,  i.e.,  its  set  of  legal  val¬ 
ues.  In  the  model,  a  state  s  is  a  function  that  maps 
each  variable  r  to  some  value  in  TY(r).  A  condition 
is  a  predicate  defined  on  the  system  statd^ -whereas  an 
event  is  a  predicate  defined  on  two  successive  system 
states  that  denotes  some  change  between  those  states. 
The  notation  “@T(c)  WHEN  dt'  denotes  a  conditioned 
event ,  defined  as 

@T(c)  WHEN  d  d=  -if  A  c'  A  d, 

where  the  unprimed  conditions  c  and  d,  are  evaluated  in 
the  old  >i  ale.  and  the  primed  condition  c'  is  evaluated 
in  the  new  state.  Informally,  “@T(c)  WHEN  <i”  means 
that  c  was  false  in  the  old  state  and  has  changed  to  tr  ue 
in  the  new  state,  while  d,  was  true  in  the  old  state  buf 
is  unrestricted  in  the  new  state.  The  notation  “@F(c)” 
is  defined  by  @F(c)  =  @T(-ic).  In  reasoning  about, 
conditions  c  and  d,  we  say  that  c  strengthens  d,  (also 
expressed  as  c  <  d)  if  c  =y  d,  is  a  tautology,  but  c  d. 
In  this  paper,  both  ->c  and  c  denote  the  negation  of 
condition  c. 

3  Mode  Classes  and  Mode  Invariants 

Thf  three  kinds  of  tables  found  in  most  SCR  specifica¬ 
tions  are  mode  transition  tables,  condition  tables,  and 
event  tables.  While  the  focus  in  this  paper  is  on  gener¬ 
ating  invariants  from  mode  transition  tables,  Section  5 
describes  how  invariants  can  be  obtained  from  condition 
tables  and  event  tables. 

In  isolation,  a  mode  class,  its  inputs,  and  the  as¬ 
sociated  transitions — which  we  call  a  mode  machine — 
may  be  viewed  as  a  very  simple  system  S  with 
a  single  output,  a  mode  class.  A  mode  transi¬ 
tion  table  represents  the  transitions  of  a  mode  ma¬ 
chine  in  a  tabular  format.  The  inputs  of  the  mode 
machine  are  the  variables  appearing  in  the  predi¬ 
cates  that  define  the  transitions.  Table  1  contains  a 
mode  transition  table,  part,  of  an  SCR  specification 
for  the  Automobile  Cruise  Control  System  [18].  In 
this  system,  the  set.  of  state  variables  RF  is  defined 
by  RF  =  {ignOn,  Lever,  EngRunning,  Brake,  M}, 
where  IgnOn,  Lever,  EngRunning,  and  Brake  are 
monitored  variables  and  M  is  a.  mode  class  with 
values  in  the  set.  {Of f,  Inactive,  Cruise,  Override}. 
The  variables  IgnOn,  EngRunning,  and  Brake  are 
boolean;  the  variable  Lever  has  the  enumerated  type 
{off,  const,  resume,  release}.  In  the  initial  states 
of  Cruise  Control,  both  IgnOn  and  EngRunning  are  false 
and  M  =  Off. 

Table  1  defines  the  transform  T  for  this  simple  sys¬ 
tem.  T  maps  the  old  state  and  an  event.,  a.  change  in 


the  value  of  one  of  the  monitored  variables,  to  a.  new 
state.  For  example,  the  fourth  row  of  Table  1  states 
that  if  the  system  is  currently  in  a.  state  where  the  mode 
is  Cruise  and  the  event.  @F( IgnOn)  occurs,  then,  in 
the  new  state,  the  mode  is  Off.  If,  in  a.  given  state, 
none  of  the  events  defining  transitions  from  the  current, 
mode  occur  (yet.  some  input,  event,  has  occurred),  then 
there  is  no  change  in  mode.  For  example,  if  the  sys¬ 
tem  is  in  Cruise  mode  in  the  old  state  and  some  input, 
event,  occurs,  but.  none  of  @F(IgnOn),  @F( EngRunning), 
@T(Brake),  or  @T(Lever  =  off)  occurs,  then  the  sys¬ 
tem  remains  in  Cruise  mode  in  the  new  state. 

A  mode  invariant  for  mode  m,  M  =  m  =y  P(m ), 
is  a.  special  case  of  a.  state  invariant.,  where  P(m)  is  a. 
proposition  over  the  state  variables.  For  example,  four 
mode  invariants  of  the  Cruise  Control  System  that  can 
be  derived  from  Table  1  and  other  information  about, 
the  Cruise  Control  System,  such  as  environmental  con¬ 
straints  and  assumptions  about,  the  initial  states,  are 

•  M  =  Off  =y  -ilgnOn 

•  M  =  Cruise  =y  IgnOn  A  EngRunning  A  'Brake  A 
Lever  y^  off 

•  M  =  Override  =y  IgnOn  A  EngRunning 

•  M  =  Inactive  =y  IgnOn 

4  Mode  Invariant  Generation 

Our  technique  automatically  generates  mode  invariants 
from  propositional  formulas  derived  from  a.  mode  ma¬ 
chine  and  constraints  on  the  input,  variables  associated 
with  that  mode  machine.  To  compute  the  mode  invari¬ 
ants  for  a.  mode  class  M ,  we  first,  identify  the  set.  of 
atomic  conditions  appearing  in  the  events  of  the  mode 
transition  table  for  M .  For  example,  in  the  Cruise  Con¬ 
trol  specification,  we  have  I  =  IgnOn,  E  =  EngRunning, 
B  =  Brake,  O  =  Lever=off ,  C  =  Lever=const,  R  = 
Lever=resume,  and  L  =  Lever=release.1  Below,  the 
term  literal  refers  to  either  an  atomic  condition  or  its 
negation.  The  algorithm  consists  of  the  following  three 
steps: 

1.  For  each  mode  m,  compute  the  mode  entry  condi¬ 
tion  N(m),  the  disjunction  of  the  conditions  i  rue 
upon  entry  into  mode  m  from  other  modes  or  upon 
entry  into  an  initial  state  when  M  =  m. 

2.  For  each  mode  m,  compute  the  unconditional  exit- 
set  X '(in),  where  X(m)  is  the  set  of  literals  whose 
falsification  cause  unconditional  exit,  from  m  . 

3.  For  each  mode  m,  compute  the  mode  invariant 
P(m)  by  eliminating  from  each  disjunct,  in  N (m) 

1  All  four  values  of  Lever  must  be  considered,  even  though  the  table 
mentions  only  three  of  them. 


Event 


@T(lgnOn) 

@F(lgnOn) 

@T(Lever  =  const)  WHEN  IgnOn  AND 
EngRunning  AND  NOT  Brake 
@F(lgnOn) 

@F  (EngRunning) 

@T(Brake)  OR  @T(Lever  =  off) 
@F(lgnOn) 

@F  (EngRunning) 

@T(Lever  =  resume)  WHEN  IgnOn  AND 
EngRunning  AND  NOT  Brake  OR 
@T(Lever  =  const)  WHEN  IgnOn  AND 
EngRunning  AND  NOT  Brake 


New  Mode 

Inactive 

Off 

Cruise 

Off 

Inactive 

Override 

Off 

Inactive 

Cruise 


Initially:  M  =  Off  A  -TgnOn  A  -lEngRunning 


Table  1:  Mode  Transition  Table  for  Cruise  Control. 


all  literals  that  are  not  members  of  X(m).  More 
precisely,  replace  each  literal  that  is  not  in  X(m) 
by  irue. 

In  the  examples  below,  only  an  intuitive  special  case 
of  step  3  is  needed:  that  is,  M  =  m  =>•  c  is  a  mode 
invariant  if  c  is  true  in  each  disjunct  of  N (m)  and  c  is 
a  conjunction  of  literals  in  X(m). 

The  algorithm  repeats  these  three  steps  until  a  fix- 
point  is  reached.  Let  Ni(m),  Xi(m),  and  Pi(m)  repre¬ 
sent  the  values  of  the  mode  entry  condition,  the  uncon¬ 
ditional  exit  set,  and  the  invariant  for  mode  m  at  the 
end  of  the  ith  pass  of  the  algorithm.  During  each  pass 
of  the  algorithm,  the  information  in  the  table  as  well  as 
a  number  of  additional  facts  may  be  used  to  strengthen 
the  invariant  computed  at  that  pass.  The  additional 
facts  include  the  initial  state  predicate  (a  predicate  de¬ 
scribing  the  states  s  £  So),  environmental  constraints, 
such  as  the  One  Input  Assumption  and  constraints  on 
enumerated  type  variables,  and  invariants  computed  on 
previous  passes.  A  constraint  on  an  enumerated  type 
(needed  due  to  our  boolean  encoding)  simply  states  that 
if  an  enumerated  type  variable  has  one  value,  it  cannot 
have  other  values.  For  example,  in  the  Cruise  Control 
System,  if  Lever  has  the  value  const,  it  cannot  have 
any  other  value;  more  precisely,  C  -O-  OaRaL. 

Table  2  summarizes  the  results  of  applying  the  al¬ 
gorithm  to  the  mode  transition  table  shown  in  Table  1. 
Applying  the  algorithm  generates  the  four  invariants 
listed  at  the  end  of  the  previous  section.  For  each  pass  i, 
Table  2  shows  the  mode  entry  condition  Ni(m),  the 
unconditional  exit  set  A8(m),  and  the  invariant  Pi(m) 
computed  during  that  pass  for  each  of  the  four  modes  m 
in  the  mode  class  M .  For  each  mode  m  and  each  pass  i, 
the  table  identifies  the  additional  facts  that  were  used 
to  strengthen  the  invariant.  Table  2  shows  that,  for  this 
example,  four  passes  are  needed  to  reach  a  Hxpoint. 

Below,  we  describe  how  the  information  in  Table  2 
and  the  additional  facts  described  above  are  used  to 


compute  the  four  mode  invariants.  Although  each  step 
of  the  algorithm  is  actually  applied  to  all  modes  at 
once,  below  we  simplify  our  description  of  the  algo¬ 
rithm  by  treating  one  mode  at  a  time.  Generating 
the  invariant  for  the  mode  Off  uses  information  from 
Table  1  as  well  as  the  initial  state  predicate.  Gener¬ 
ating  the  invariant  for  the  mode  Cruise  shows  how 
the  One  Input  Assumption  and  the  constraints  on  an 
enumerated  type  variable  are  used  to  strengthen  the 
mode  entry  condition  computed  from  Table  1,  which  in 
turn  strengthens  the  computed  invariant.  In  generat¬ 
ing  the  invariant  for  the  mode  Override,  an  invariant 
generated  on  the  first  pass  for  a  different  mode  is  used 
to  strengthen  the  mode  entry  condition  computed  in 
the  second  pass.  Then,  the  strengthened  mode  entry 
condition  is  used  to  strengthen  the  computed  invari¬ 
ant.  Computing  the  strongest  invariant  for  the  mode 
Inactive  requires  three  passes  of  the  algorithm.  In  the 
second  and  third  passes,  invariants  generated  for  other 
modes  during  the  first  and  second  passes  are  used  to 
strengthen  the  mode  entry  condition  and  subsequently 
the  mode  invariant  for  Inactive. 

To  apply  the  algorithm  to  the  mode  Off,  we  first 
analyze  rows  2,  4,  and  7,  the  three  rows  of  Table  1  that 
cause  the  system  to  enter  the  Off  mode.  In  each  case, 
the  condition  that  holds  upon  entry  into  Off  is  -TgnOn, 
denoted  as  I.  Next,  because  M  =  Off  holds  in  the 
initial  state,  we  can  also  include  part  of  the  initial  state 
predicate  (namely,  -TgnOn  A  -lEngRunning,  denoted 
as  IaE)  in  the  mode  entry  condition.  Thus,  the  mode 
entry  condition  is  AG  (Off)  =  I  V  I  V  I  V  IaE  =  I. 
In  the  second  step,  we  analyze  row  1,  the  only  row  of 
Table  1  that  describes  an  exit  from  Off,  to  compute 
the  unconditional  exit  set  Xi(Off).  The  only  condition 
whose  falsification  causes  unconditional  exit  from  Off 
is  -i IgnOn.  Hence,  Xi(Off)  =  {/}.  In  the  third  step, 
we  restrict  the  mode  entry  condition  to  the  members  of 
the  unconditional  exit  set  to  obtain  T’i(Off)  =  I,  and 
hence  the  mode  invariant  M  =  Off  =>•  -TgnOn. 


i 

Mode  m 

Ni(m) 

Xt(m) 

Pi{m) 

Comments 

i 

Off 

7  v  7  v  7  v  IaE 

m 

7 

ISP  gives  4th  DJ 

Inactive 

i  v  77  v  77 

{ i } 

true 

— 

Override 

B  v  o 

{ I,E } 

irue 

— 

Cruise 

CaIaEaBaOaRaL  V  RaIaEaBaOaCaL 

{ I,E,B,0 } 

IaEaBaO 

Apply  OIA,  CET 

2 

Off 

7  v  7  v  7  v  7aE 

{1} 

i 

Fixpoint  reached? 

Inactive 

I  v  7Ja/aOa77  v  E 

{1} 

true 

Apply  Pi  (Cruise),  OIA  to  2nd  DJ 

Override 

BaIaEaO  V  OaIaEaBaCaRaL 

{ I,E } 

IaE 

Apply  Pi  (Cruise),  OIA,  &;  CET 

Cruise 

CaIaEaBaOaRaL  v  RaIaEaBaOaCaL 

{ I,E,B,0 } 

IaEaBaO 

Fixpoint  reached? 

3 

Off 

7  v  7  v  7  v  7aE 

{T} 

1 

Fixpoint  already  reached? 

Inactive 

I  V  EaIaOaB  V  EaI 

{ I } 

I 

Apply  P2  (Override),  OIA  to  3rd  DJ 

Override 

BaIaEaO  v  OaIaEaBaCaRaL 

{ I,E } 

IaE 

Fixpoint  reached? 

Cruise 

CaIaEaBaOaRaL  v  RaIaEaBaOaCaL 

{ I,E,B,0 } 

IaEaBaO 

Fixpoint  already  reached? 

4 

Off 

7  v  7  v  7  v  IaE 

{1} 

1 

Fixpoint  reached! 

Inactive 

I  v  EaIaOaB  v  EaI 

{1} 

I 

Fixpoint  reached! 

Override 

BaIaEaO  v  OaIaEaBaUaRaL 

{ I,E } 

IaE 

Fixpoint  reached! 

Cruise 

CaIaEaBaOaRaL  v  RaIaEaBaOaCaL 

{ I,E,B,0 } 

IaEaBaO 

Fixpoint  reached! 

Key 


ISP: 

Initial  State  Predicate 

I: 

IgnOn 

OIA: 

One  Input  Assumption 

E 

EngRunning 

CET: 

Constraint  from  Enumerated  Type 

B 

Brake 

N,(m ): 

Mode  Entry  Condition  for  Mode  m  at  Ah  pass 

O 

Lever 

—  off 

Xi(m): 

Unconditional  Exit  Set  for  Mode  m  at  Ah  pass 

C 

Lever 

=  const 

Pi(m): 

Invariant  computed  for  Mode  m  at  Ah  pass 

R 

Lever 

=  resume 

DJ: 

Disjunct  of  Nz(m) 

L 

Lever 

=  release 

Table  2:  Mode  Invariant  Generation  for  Cruise  Control 


Next,  we  use  our  algorithm  to  generate  a  mode  in¬ 
variant  for  the  mode  Cruise.  First,  we  use  rows  3  and  9, 
the  two  rows  of  Table  1  that  cause  entry  into  Cruise,  to 
compute  the  mode  entry  condition.  The  One  Input  As¬ 
sumption  guarantees  that  the  conditions  in  the  WHEN 
clauses  remain  true  upon  entry  into  Cruise;  hence,  for 
example,  the  conditioned  event  in  row  3  and  the  One 
Input  Assumption  imply  that,  upon  entry  into  mode 
Cruise,  the  condition  C'aIaEaB  holds.  Thus,  the  mode 
entry  condition  is 

Ni  (Cruise)  =  CaIaEaB  V  [RaIaEaB  V  CaIaEaB ]. 

Further,  because  Lever  is  an  enumerated  type,  only  one 
of  the  atomic  conditions,  O ,  C ,  R,  and  L,  can  be  true  at 
a  given  time.  Hence,  constraints,  such  as  C'  O  OaRaL, 
can  be  used  to  strengthen  the  mode  entry  condition 
./Vi  (Cruise),  i.e. , 

N\ (Cruise)  =  CaIaEaBaOaRaL  V  RaIaEaBaOaCaL ? 

In  the  second  step,  we  use  rows  4-6  of  Table  1  to 
compute  the  unconditional  exit  set  X\ (Cruise)  = 
{I,E,B,0}.  Finally,  eliminating  all  literals  not  in  the 
unconditional  exit  set  from  the  mode  entry  condition 

2For  readability,  the  form  of  this  condition  has  been  simplified. 
When  used  to  strengthen  the  invariant  based  on  previously  computed 
invariants,  the  condition  must  be  expressed  in  a  form  that  distin¬ 
guishes  the  source  modes. 


produces  /^(Cruise)  =  IaEaBaO.  This  is  equivalent 
to  the  mode  invariant 

M  =  Cruise  =>•  IgnOn  A  EngRunning 

A  -iBrake  A  Lever  off.  (1) 

In  generating  an  invariant  for  the  mode  Override, 
the  first  pass  of  the  algorithm  uses  row  6  of  Table  1  to 
produce  Ni (Override)  =  B  V  O  and  rows  7,  8,  and 
9  to  produce  Xi(Override)  =  {/,  E}.  Because  no  lit¬ 
erals  in  the  unconditional  exit  set  appear  in  the  mode 
entry  condition,  after  the  first  pass,  Pi  (Override)  is 
trivially  irue.  On  the  second  pass,  the  mode  entry  con¬ 
dition  can  be  strengthened  by  recognizing  that  the  only 
mode  from  which  Override  can  be  entered  is  Cruise 
(see  row  6).  Applying  the  invariant  in  (1)  generated  for 
the  mode  Cruise  during  the  first  pass,  the  One  Input 
Assumption  and  the  constraint  on  the  enumerated  type 
Lever  strengthens  the  mode  entry  condition,  i.e., 

^(Override)  =  BaIaEaO  V  OaIaEaBaCaRaL. 

Finally,  restricting  the  mode  entry  condition  to 
the  members  of  Xi(Override)  =  {/,  E}  produces 

/^(Override)  =  IaE,  i.e.,  the  invariant 

M  =  Override  =>•  IgnOn  A  EngRunning.  (2) 

To  generate  an  invariant  for  the  mode  Inactive, 
rows  1,  5,  and  8  of  Table  1  are  used  to  compute 


Mode 

Events 

High 

False 

@F(Pressure  =  High) 

TooLow, 

@T(Block  =  On) 

@T(Pressure  =  High)  OR 

Permitted 

WHEN  Reset  =  Off 

@T(Reset  =  On) 

Overridden 

True 

False 

Table  3:  Event  Table  for  Overridden  in  Standard  Format. 


Old  Value 

Event 

New  Value 

FALSE 

@T(Block  =  On)  WHEN  Reset  =  Off  AND 
Pressure  7^  High 

TRUE 

TRUE 

@T(Reset  =  On)  WHEN  Pressure  7^  High  OR 
@T(Pressure  =  High)  OR  @F(Pressure  =  High) 

FALSE 

Table  4:  Event  Table  for  Overridden  Rewritten  as  a  Mode  Transition  Table. 


Ni( Inactive)  =  I  V  E  V  E  and  rows  2  and  3  to  com¬ 
pute  A'j^Inactive)  =  {/}.  In  step  3,  we  note  that  E, 
which  appears  as  the  second  disjunct  in  ^(Inactive), 
does  not  appear  in  the  unconditional  exit  set  {/}. 
Hence,  we  replace  E  with  true  in  Ni( Inactive),  thus 
producing  the  trivial  invariant  .Pi (Inactive)  =  true. 
The  second  pass  uses  the  One  Input  Assumption  and 
the  invariant  (1)  computed  during  the  first  pass  for 
Cruise  to  strengthen  the  mode  entry  condition,  that 
is,  AC (Inactive)  =  7  V  [ EaIaOaB \  V  E.  (The  third 
disjunct  E ,  the  mode  entry  condition  when  the  current 
mode  is  Override,  cannot  be  strengthened  because  the 
invariant  computed  for  Override  during  pass  1  is  true.) 
Applying  step  3  at  the  second  pass  produces  no  change 
in  the  mode  invariant.  Finally,  on  the  third  pass,  the 
One  Input  Assumption  and  the  invariant  (2),  computed 
for  Override  during  the  second  pass,  can  be  used  to 
rewrite  the  mode  entry  condition  as  #3  (Inactive)  = 
7  V  [ EaIaOaB ]  V  [EaI],  Restricting  the  mode  entry 
condition  to  the  single  member  7  of  the  unconditional 
exit  set  produces  Ps( Inactive)  =  7,  which  is  equivalent 
to  the  mode  invariant  M  =  Inactive  =>  IgnOn. 

An  analysis  of  Table  2  shows  that,  for  each  mode  773  , 
the  exit,  set  computed  at  pass  1,  A'i(m),  predicts  the 
invariant  computed  at  pass  4,  P^(m).  As  the  example 
in  the  next  section  shows,  this  is  generally  not  the  case. 

In  the  example  shown  in  Table  2,  reaching  a  Hxpoint. 
requires  four  passes.  The  number  of  needed  passes  can 
often  be  reduced  by  computing  the  invariants  in  a  dif¬ 
ferent  order  and  applying  an  invariant  as  soon  as  it  is 
computed  rather  than  waiting  until  the  next  pass.  To 
illustrate  this  approach  in  the  Cruise  Control  example, 
we  use  an  alternate  ordering:  Off,  Cruise,  Override, 
and  Inactive.  During  pass  1,  the  mode  invariant  com¬ 
puted  earlier  for  Cruise  can  be  used  to  strengthen  the 
mode  entry  condition  for  Override  and  the  mode  in¬ 
variants  for  Cruise  and  Override  to  strengthen  the 
mode  entry  condition  for  Inactive.  This  leads  to 
strengthened  mode  invariants  at  the  first  pass,  rather 
than  later  passes,  with  the  Hxpoint  reached  during  the 
second  pass. 


5  Generating  Invariants  from  Other  Tables 

The  previous  section  described  our  algorithm  for  gener¬ 
ating  mode  invariants  from  mode  transition  tables.  This 
section  shows  how  this  algorithm  can  be  used  to  gener¬ 
ate  state  invariants  from  event  tables  and  also  presents 
an  example  of  a  state  invariant  derived  from  a  condition 
table.  Because  the  invariant  is  easily  derived  from  the 
semantics  of  condition  tables,  applying  our  algorithm 
is  unnecessary.  We  also  show  by  example  how  these 
generated  invariants  may  be  used  to  prove  additional 
invariants . 

Consider  the  event  table  in  Table  3,  part  of  a  re¬ 
quirements  specification  for  a  simple  system  control¬ 
ling  safety  injection  in  a  nuclear  plant.  (This  ta¬ 
ble,  equivalent  to  a  similar  table  in  [17],  avoids  the 
“Inmode”  notation.)  Table  3,  which  describes  when 
safety  injection  is  overridden,  can  be  viewed  as  a  simple 
SCR  system  S  whose  monitored  variables  are  Block, 
Reset,  and  Pressure  and  whose  single  controlled  vari¬ 
able  is  Overridden.  In  the  initial  states  of  the  sys¬ 
tem,  Pressure  =  TooLow  A  Overridden  =  false  A 
Saf  etylnj  ection  =  On. 

Before  our  algorithm  can  be  applied  to  an  event  ta¬ 
ble,  the  table  must  be  represented  in  the  format  of  a 
mode  transition  table.  To  accomplish  this,  we  first 
treat  each  mode  in  the  first  column  of  the  event  table  as 
an  additional  condition  in  the  WHEN  clause  of  condi¬ 
tioned  events  in  the  appropriate  row.  Then,  the  table  is 
rewritten  to  describe  the  variable  transitions — how  the 
variable  defined  by  the  table  changes  from  one  value  to 
any  other  possible  value.  If  a  variable  has  n  possible 
values,  there  are  n2  On  possible  transitions  (excluding 
self-transitions).  In  the  case  of  Table  3,  the  variable 
Overridden  has  only  two  values,  so  only  two  transi¬ 
tions  are  needed,  the  transition  from  TRUE  to  FALSE3 
and  vice  versa.  Rewriting  the  event  table  in  Table  3  in 
the  form  of  a  mode  transition  table  produces  Table  4. 

To  generate  a  state  invariant  involving  Overridden, 

3To  avoid  confusion  with  the  truth  values  false  and  true ,  we  denote 

the  values  of  Overridden  as  FALSE  and  TRUE. 


three  atomic  conditions  are  defined:  R  =  Reset=0n, 
B  =  Block=0n,  and  H  =  Pressure=High.  (The 
negations  of  B  and  R  have  the  obvious  meaning;  e.g., 
B  =  Block=0ff.)  Applying  the  algorithm  when 
Overridden  has  the  value  FALSE  computes  the  unin¬ 
teresting  Pi( FALSE)  =  true. 

On  the  first  pass  of  the  algorithm  when  Overridden 
is  TRUE,  we  compute  AG (TRUE)  =  BaRaH  (assuming  the 
One  Input  Assumption)  and  A'i(TRUE)  =  {H ,  H}.  This 
yields  .Pi (TRUE)  =  H,  i.e . ,  the  state  invariant 

Overridden  =  TRUE  =>  Pressure  y^  High. 

On  the  second  pass,  the  mode  entry  condition  cannot  be 
strengthened,  but  the  invariant  computed  on  the  first 
pass  allows  us  to  revise  the  unconditional  exit  set.  Since 
Overridden  =  TRUE  =a  H  is  an  invariant,  we  deduce 
from  Table  4  that  the  event  @T(Reset=0n)  causes  un¬ 
conditional  exit  from  TRUE.  Hence,  on  the  second  pass, 
the  unconditional  exit  set  AA(TRUE)  is  {H ,  H ,  f?},  which 
produces  the  strengthened  invariant  P^TRUE)  =  HaR, 
i.e., 

Overridden  =  TRUE  => 

Pressure  y^  High  A  Reset  =  Off.  (3) 


Mode 

Conditions 

High,  Permitted 

True 

False 

TooLow 

Overridden 

NOT  Overridden 

Safety  Injection 

Off 

On 

Table  5:  Condition  Table  for  Safety  Injection. 

Table'  h  is  a  condition  table,  taken  from  the  same 
specification  as  Table  3,  which  specifies  when  the  sys¬ 
tem  turns  safety  injection  on  and  off.  The  semantics  of 
condition  tables  presented  in  [17]  requires  the  conditions 
Ci  in  each  row  of  the  table  to  satisfy  two  properties:  the 
disjunction  of  the  c,;  is  true,  and  the  pairwise  conjunc¬ 
tion  of  Ci  and  cj,  i  y^  j,  is  false.  Using  this  semantics 
along  with  the  assumption  about,  initial  states,  we  can 
easily  derive  the  following  state  invariants  from  Table  5, 

Saf etylnjection  =  On  AA 

Pressure  =  TooLow  A  -lOverridden,  (4) 

and  its  equivalent  form, 

Saf etylnjection  =  Off  AA 

Pressure  y^  TooLow  V  Overridden. 

In  [6],  the  following  two  properties  of  the  Safety  In¬ 
jection  System  are  proved  using  model  clicking: 


Property  X:  Reset  =  On  A  Pressure  y^  High 

=y  -lOverridden 

Property  Y:  Reset  =  On  A  Pressure  =  TooLow 

=>  Saf  etylnj ection  =  On 

Property  X  is  easily  derived  from  the  invariant  in  (3), 
since  (3)  is  stronger.  Moreover,  Property  Y  follows  di¬ 
rectly  from  (3)  and  (4).  This  result  suggests  that  our  in¬ 
variant.  generation  algorithm  can,  at.  times,  supplement, 
other  techniques,  such  as  model  checking,  in  verifying 
properties  of  state  machine  models. 

6  Generalizing  the  Algorithm 

This  section  generalizes  our  algorithm  by  describing  for¬ 
mally  how  the  algorithm  can  be  applied  to  general  state 
machine  models.  The  current.  SCR  requirements  model 
is  a.  special  case  of  this  general  model.  The  general 
model  allows  the  transform  T  to  be  nondet.erminist.ic, 
that,  is,  a.  relation  rather  than  a.  function,  and  makes 
very  general  assumptions  about,  the  environment. — the 
One  Input.  Assumption  and  NAT  constraints  of  the  cur¬ 
rent.  SCR  model  are  special  cases.  Further,  the  events 
defining  transitions  a.rq  not.  limited  to  the  special  un¬ 
conditioned  event,  form  found  in  SCR  tables. 

Our  general  algorithm  for  generating  state  invari¬ 
ants  can  be  applied  to  other  state  machine  models.  For 
example,  we  have  applied  the  algorithm  to  two  SCR 
specifications  analyzed  by  At.lee  and  Gannon  [4],  whose 
SCR  semantics  omits  the  One  Input.  Assumption,  and 
corroborated  their  results.4  The  algorithm  also  applies 
to  models,  such  as  TLA  [24]  and  STeP  [27],  whose; tran¬ 
sitions  are  expressed  as  changes  in  one  or  more  system 
variables.  In  other  models,  such  as  Statecharts  [14]  and 
RSML  (Requirements  State  Machine  Language)  [25], 
which  include  hierarchical  states  and  internal  events, 
the  algorithm  is  also  applicable  but.  due  to  the  complex 
step  semantics  of  these  two  models,  applying  the  algo¬ 
rithm  would  be  less  straightforward.  A  recent,  paper  by 
Park  et.  a.l.  [31]  discusses  the  generation  of  invariants 
from  RSML  speciHca.t.ions  (see  Section  7). 

6.1  Mode  Machines  as  Abstract  State  Machines 

We  consider  a.  system  as  a.  state  machine  X  =  (S,  0,p), 
where  S  is  the  set.  of  states,  0  is  the  initial  st.a.t.#  predi¬ 
cate,  and  p  is  the  next-state  relation  on  pairs  of  states. 
To  define  the  state  machine  X  corresponding  to  an  SCR 
machine  represented  as  (S',  So,  Em ,  T ),  we  define  (1)  the 
initial-state  predicate  0  on  a.  state  s  £  S  such  that  0(s) 
is  true  iff  s  £  So  and  (2)  the  next-state  predicate  p  on 

4 In  later  work,  Sreemani  and  Atlee  [33]  use  a  semantics  for  SCR 
equivalent  to  ours,  adopting  the  One  Input  Assumption  and  our 
WHEN  semantics. 


pairs  of  states  s,s'  E  S  such  that  p(s,s')  is  true  iff 
there  exists  an  event  e  E  Em ,  enabled  in  s,  such  that 
T(e,s)  =  s'.  Thus  the  predicate  p  is  simply  a  concise 
and  abstract  way  of  expressing  the  transform  T  without 
reference  to  events. 

Consider  two  state  machines,  £  =  (S,Q,p)  and 
T,a  =  (Sa, ®a,  Pa)-  Then,  YA  is  an  abstraction  of  £  if 
there  is  a  map  a  :  S  — >■  Sa,  s  A  sa,  called  the  abstrac¬ 
tion  map,  such  that  (a)  for  all  s  in  S:  0(s)  =>■  ©/l(s/l) 
and  (b)  for  all  s,  s'  in  S:  p(s,  s')  =>•  Pa(sa ,  s^).  A  mode 
machine  is  an  example  of  an  abstract  state  machine 
The  original  specification,  which  includes  the  mode  ma¬ 
chine  as  a  component,  describes  the  state  machine  £. 

We  guarantee  that  a  mode  invariant  qA  computed  for 
a  mode  machine  YA  has  a  corresponding  mode  invariant 
Z(qa)  in  the  overall  state  machine  £  if  the  following 
theorem  is  satisfied: 

Theorem  1  Let  £  =  (S,Q,p)  and  YA  =  (Sa,®a,  Pa) 
be  two  state  machines,  and  let  a  be  an  abstraction 
map  from  S  to  Sa-  If  condition  qA  is  an  invari¬ 
ant  for  YA,  then  Z(qA)  is  an  invariant  for  £  where 
Z(<1a)  =  {  s  |  qA(sA )  }• 

This  theorem  is  a  special  case  of  Theorem  1.1,  Part  1, 
in  [2].  It  is  also  a  special  case  of  Corollary  5.7  in  [9], 
which  is  generalized  in  [26]. 

To  obtain  the  abstraction  map  ex,  we  can  often  ap¬ 
ply  the  three  abstraction  methods  for  SCR  systems  de¬ 
scribed  in  [6,  15]  to  the  specification  of  the  state  ma¬ 
chine  £  to  obtain  the  specification  of  the  mode  machine 
Abstraction  Method  1  eliminates  all  variables,  ex¬ 
cept  those  on  which  the  mode  class  depends.  Abstrac¬ 
tion  Method  2  removes  detailed  monitored  variables 
(i.e.,  variables  with  large  ranges  of  values),  while  Ab¬ 
straction  Method  3  replaces  detailed  variables  (perhaps 
with  infinitely  many  values)  with  more  abstract,  finite- 
valued  variables.  Encoding  the  variables  as  atomic  con¬ 
ditions  is  then  required.  Normally,  we  encode  a  finite 
type  using  one  atomic  condition  for  each  value  of  the 
type. 

Suppose  M  is  a  mode  class,  TY (M)  the  set  of  possi¬ 
ble  values  (i.e.,  modes)  of  M ,  and  Ea  the  set  of  events  in 
the  mode  transition  table  for  M ,  where  each  e  E  Ea  is 
represented  as  a  logical  formula  over  the  encoded  atomic 
conditions.  Then,  the  mode  machine  for  the  mode  class 
M  is  defined  by  four  constructs:  the  relation  Ya  de¬ 
scribing  the  mode  transitions,  the  initial  state  predicate 
0^4,  and  two  constraints  C\  and  C 2  on  the  monitored 
variables.  C\  and  C 2  capture  the  environmental  con¬ 
straints  described  in  the  previous  examples.  The  con¬ 
structs  Ya,  0^4 ,  C 1,  and  C 2  are  represented  as  follows: 

•  Ya  is  a  relation  on  TY(M)  x  Ea  x  TY(M).  In 
SCR  specifications,  this  relation  is  represented  by 
the  encoded  form  of  the  mode  transition  table 


for  M .  We  assume  that  Ya  omits  self-transitions, 
i.e.,  transitions  of  the  form  (m,  e,  m). 

•  0/i  is  the  condition  over  YA  which  describes  the 
initial  states.  Additionally,  we  define  the  initial 
states  associated  with  each  m  as 

0A(m)  =  QA\M:=m, 

where  QA\M:=m  is  ©a  with  all  appearances  of  the 
variable  M  replaced  with  m.  For  example,  in  the 

H  pf"  —  — 

Cruise  Control  System,  ®A  =  M  =  Off  A/Mi; 
therefore,  0A( Off)  =  I  A  E,  and  ^(m)  =  false 
otherwise. 

•  Ci  is  a  conjunction  of  encoded  constraints  on  mon¬ 
itored  variables  in  a  single  state.  Among  these 
constraints  are  the  axioms  needed  to  encode  fi¬ 
nite  types  as  booleans.  For  example,  in  the  Cruise 
Control  System,  Ci  is  the  axiom 

(C  <=>  OaRaL)  A  (O  <=>  CaRaL)  A 
(R  <=>  OaCaL)  A  (L  <=>  OaC'aR). 

Other  constraints  are  derived  from  NAT;  for  ex¬ 
ample,  in  the  Cruise  Control  System,  a  possible 
physical  constraint  (not  used  in  our  case)  is  that 

E  =>■  I  (i.e.,  EngRunning  =>•  IgnOn  [4]). 

•  C 2  is  a  conjunction  of  encoded  constraints  on  mon¬ 
itored  variables  in  two  consecutive  states.  One 
possible  constraint  C 2  for  the  Cruise  Control  sys¬ 
tem  is  the  One  Input  Assumption.  Other  possi¬ 
bilities  are  physical  constraints;  one  example  (not 
used  here)  is  the  encoded  version  of  the  constraint: 
when  Lever  yZ  release  and  Lever  changes,  the 
only  possible  transition  is  Lever'  =  release. 

We  have  shown  that  with  some  restrictions  (easily  met 
in  practice)  that  the  state  machine  YA  defined  by  the 
above  constructs  satisfies  Theorem  1  [22]. 

6.2  Details  of  Mode  Invariant  Generation 

In  addition  to  the  four  constructs  defined  above,  our 
algorithm  uses  three  functions — NEW,  EX,  and  KEEP. 
To  compute  the  the  mode  entry  condition,  Step  1  uses 
NEW,  which  extracts  the  new  state  information  from  a 
two-state  predicate.  To  compute  the  unconditional  exit 
set,  Step  2  uses  EX,  which  describes  the  events  causing 
exit  from  a  mode.  Finally,  to  compute  the  mode  invari¬ 
ant,  Step  3  uses  KEEP,  a  projection  operator.  Below, 
we  describe  these  three  functions  and  then  use  them  to 
define  the  generalized  version  of  our  algorithm. 

The  function  AT  IT  has  a  single  argument  q,  a  predi¬ 
cate  on  two  states  expressed  in  Disjunctive  Form.  More 
precisely,  q  is  the  disjunction  of  non-false  terms,  each  of 
which  is  either  true  or  the  conjunction  of  one  or  more 


literals  l  or  £' .  (Any  two-state  predicate  can  be  ex¬ 
pressed  in  Disjunctive  Form,  since  any  two-state  pred¬ 
icate  can  be  expressed  in  standard  disjunctive  normal 
form,  a  special  case.)  The  function  NEW  computes 
the  strongest  condition  known  to  be  true  in  the  new 
state.  Applying  NEW  to  a  two-state  predicate  simply 
replaces  each  old  state  literal  with  true  and  suppresses 
the  primes  on  the  remaining  new  state  literals.  For  ex¬ 
ample,  the  following  shows  the  application  of  NEW  to 
the  conjunction  of  the  event  in  the  first  line  of  Table  4 
and  an  appropriate  part  of  the  One  Input  Assumption 
(shown  in  brackets): 

NEW((@T(B)  WHEN  RaH)  A 

[B'  ±  B  =>  R'  =  R  A  H'  =  H])  = 

NEW(BaB'aRaHa^/JI')  =  BaRaH. 

For  the  formal  definition  of  NEW,  see  the  Appendix. 

The  function  EX  is  a  two-state  predicate  which  de¬ 
scribes  the  events  causing  exit  from  a  mode  as  a  dis¬ 
junction.  For  example,  in  the  Cruise  Control  System, 
lines  2  and  3  of  Table  1  show  that  T'A(lnactive)  should 
be  defined  as 

^(Inactive)  =  @F(J)  V  @T(C)  WHEN  (IaEaB). 
Formally,  EX  is  defined  by 

EX(m)  =  \/ 

The  function  KEEP  has  two  arguments,  a  set  U 
of  literals  and  a  condition  c  (i.e. ,  a  one-state  predi¬ 
cate)  expressed  in  Disjunctive  Form.  Then,  KEEP(U,  c) 
is  c  with  all  literals  l  that  are  not  in  U  replaced  by 
true.  For  example,  consider  U  =  X2 (Override)  and 
c  =  #2 (Override)  from  Table  2: 

KEEP  {{I,  E},  BaIaEaO  V  OaIaEaBaCaRaL)  = 
IaE  V  IaE  =  IaE 

For  the  formal  definition  of  KEEP,  see  the  Appendix. 

The  mode  entry  condition  Ni(m)  for  a  given  mode 
m  at  the  ith  pass  is  defined  in  terms  of  Oa(th),  the  in¬ 
variants  computed  on  the  previous  pass,  the  constraints 
Ci  and  C2,  and  the  events  e  causing  entry  into  m.  For¬ 
mally,  Ni(m)  is  defined  by 

Ni(m)  =  Oa(iti)  A  Ci 

VI  \/  NEW(Pi-i(rri)  A  C2  A  e)  )  A  Ci. 

\  m,e:Y>i(^,e,m)  / 

To  demonstrate  that  this  definition  correctly  captures 
our  intuitive  notion  of  “what  is  known  upon  mode  en¬ 
try,”  a  more  formal  computation  of  the  mode  entry  con¬ 
dition  N'j (Override)  for  the  Cruise  Control  follows: 


/^(Override)  =  ATW[(-Pi(Cruise)  A  C2 
A(@T(5)  V@T(0))]  A  Ci 
=  NEW[IaEaBaO  A  C2  A  (BaB'  V  OaO')]  A  Ci 
=  NEW\BaB'aIaEaOaTaE'aO' 

V  OaO'aIaEaBaPaE'aB']  A  Ci 
=  [BaIaEaO  V  OaIaEaB]  A  Ci 
=  BaIaEaO  V  OaIaEaBaCaRaL 

The  unconditional  exit  set  Xi(m)  for  a  given  mode  m 
at  the  ith  pass  is  computed  using  the  events  @F(£)  that 
cause  exit  from  m,  the  invariant  _P8_i(m)  computed  on 
the  previous  pass,  the  constraints  C2,  and  the  function 
EX.  Formally,  Xi(m)  is  defined  by 

Xi{m)={t  |  @F(£)  A  Pi-i(m) 

APi_i(m)'  AC2  =>  EX(m)}. 

To  explain  this  definition,  we  first  consider  the  simpler 
@F(£)  =>•  EX(m).  This  states  that,  for  each  £  £  Xi(m), 
@F(£)  is  either  impossible  (thus  making  the  implica¬ 
tion  vacuously  true)  or  its  occurrence  must  cause  exit 
from  mode  m.  However,  we  can  strengthen  this  sim¬ 
ple  form  by  applying  additional  facts  about  the  system 
when  in  mode  m,  i.e.,  P,'_i(m)Al5,'_i(m),AC2.  The  in¬ 
clusion  of  Pi_i(m)'  is  rather  subtle  since  it  seems  that 
we  don’t  know  that  M  =  m  in  the  new  state.  How¬ 
ever,  if  -iPi-i(m)1  then  we  know  that  EX(m)  holds  so 
we  don’t  need  to  consider  that  alternative  and  are  left 
with  Pi-\  (m)' . 

As  an  example,  consider  the  computation  of  the  in¬ 
variant  for  Overridden  =  TRUE  in  the  Safety  Injec¬ 
tion  system.  What  follows  is  the  proof  that  Reset  = 
off  is  in  the  unconditional  exit  set  computed  during 
the  second  pass,  i.e.,  R  £  X'^iTRUE): 

R  £  X2(TRUE) 

O  @F (R)  A  Pi  ( TR  UE)  A  P\ ( TR  UE)'  A  C2 
=A  EX(TRUE) 

O  @T(R)  All  AH'  AC2 

^@T(R)AH  V  @T (H)  V  @F (H) 

Given  the  mode  entry  condition  Ni(m)  and  the  un¬ 
conditional  exit  set  Xi(m)  at  the  ith  pass,  we  can  now 
compute  the  invariant  Pi(m)  at  the  ith  pass  using  the 
KEEP  operator  and  the  constraints  Ci .  Formally, 

Pi{m)  =  KEEP(Xi(m),Ni(m))  A  Ci. 

That  KEEP  computes  a  mode  invariant  in  this  equation 
is  based  upon  the  following  intuition:  Consider  the  sim¬ 
plest  case  when  the  mode  entry  condition  (in  Disjunc¬ 
tive  Form)  is  a  single  conjunction  of  literals.  Applying 


the  KEEP  operator  produces  Pi(m),  a  conjunction  of 
literals  found  in  Xi(m).  First,  we  note  that  Pi(m)  must 
be  true  upon  entry  into  mode  m  (the  KEEP  construc¬ 
tion  ensures  that  Ni(m)  =>  Pi(m)).  Then,  Pi(m)  must 
be  a  mode  invariant,  for  if  not  then  there  must  be  some 
transition  that  falsifies  Pi(m)  but  leaves  M  =  m.  This 
is  impossible  because  falsification  of  Pi(m)  requires  at 
least  one  of  the  literals  in  Pi(m)  (i.e. ,  some  £  £  Xi(m)) 
to  become  false,  which  means  that  the  system  must 
exit  m.  In  generalizing  from  the  simplest  case,  we  re¬ 
quire  the  disjunction  of  the  above  technique  over  all 
alternative  possibilities. 

To  complete  our  description  of  the  algorithm,  we  de¬ 
fine  the  initial  case 

P0(m)  =  C\. 

That  is,  the  mode  invariant  is  simply  C\  initially,  and 
we  iterate  computing  Pi(m)  for  each  m  until  a  Rxpoint  is 
reached,  i.e.,  when  there  exists  n  such  that  the  T’n_|_i(m) 
for  each  m  computed  at  step  n  +  1  equals  the  Pn(m) 
computed  at  step  n.  The  major  result  that  we  have 
proved  is  that  the  algorithm  computes  mode  invariants 
for  T,a  (see  the  Appendix  for  the  proof): 

Theorem  2  M  =  m  =>  Pi(m)  is  a  mode  invariant  for 
Ha  for  each  m  and  each  pass  i.  Furthermore,  ( M  = 
m  =>  Pi(m))  <  ( M  =  m  =>  T)_1(m)),  with  at  least  one 
invariant  strengthened  on  each  pass  i  before  the  fixpomt 
is  reached. 

As  a  corollary  to  the  proof  of  the  major  result,  we  have 
the  following  simple  test  that  a  literal  l  is  a  mode  in¬ 
variant  (Theorem  3.1  from  [3]): 

Corollary  1  M  =  m  =>•  £  is  a  mode  invariant  of  mode 
m  of  Ha  if  (a)  £  is  always  true  when  mode  m  is  entered, 
and  (b)  event  @F(7)  causes  an  unconditional  exit  from 
mode  m. 

Further,  if  Theorem  1  holds,  then  the  generated  mode 
invariants  can  be  translated  into  mode  invariants  for 
the  original  state  machine  H. 

This  algorithm  sacrifices  completeness,  i.e.,  the  abil¬ 
ity  to  generate  the  strongest  invariants,  for  ease  of  com¬ 
putation.  While  our  algorithm  makes  it  easy  to  com¬ 
pute  an  invariant,  it  does  not  necessarily  produce  the 
strongest  invariant,  i.e.,  the  invariant  that  would  result 
from  a  complete  reachability  analysis.  An  additional 
source  of  incompleteness  is  that  the  environmental  as¬ 
sumptions  may  be  too  weak;  e.g.,  the  precise  environ¬ 
mental  constraints  may  not  be  known,  so  a  conserva¬ 
tive  approximation  is  used  instead.  Incompleteness  is 
further  discussed  in  [22]. 


7  Related  Work 

Our  technique  for  generating  invariants  from  SCR  spec¬ 
ifications  extends  work  by  Atlee  and  Gannon  [3,  4],  who 
used  hand-computed  mode  invariants  in  their  analysis 
of  SCR  specifications  using  the  MCB  model  checker  [8]. 
However,  their  technique  was  not  automatable  and  only 
addressed  a  special  case  of  our  general  algorithm.  They 
derived  mode  invariants  where  the  Pi(m)  were  conjunc¬ 
tions  of  conditions  (rather  than  general  expressions), 
handled  limited  event  expressions  (rather  than  general 
events),  and  handled  only  special  cases  of  the  environ¬ 
mental  constraints  C\  and  C*2. 

Mode  invariants  are  analogous  to  local  invariants, 
where  a  local  invariant  PC  =  i  =>•  I(i)  is  a  property 
that  holds  when  a  program  is  in  location  i.  In  par¬ 
ticular,  mode  invariants  are  related  to  the  subclass  of 
“reaffirmed  invariants”:  local  invariants  defined  on  data 
variables  [27].  The  Stanford  Temporal  Prover  [27]  au¬ 
tomatically  generates  such  invariants. 

Bensalem  and  his  colleagues  have  recently  refined 
techniques  for  generating  local  invariants  [5].  However, 
their  generation  process  is  considerably  different  from 
ours.  They  first  generate  invariants  that  hold  for  each 
process  in  isolation.  This  consists  of  “generalized  reaf¬ 
firmed  invariants  without  cycles”  which  are  analogous 
to  our  computation  of  mode  entry  conditions.  Next, 
these  invariants  are  propagated  within  each  isolated 
process.  Finally,  the  invariants  from  the  isolated  pro¬ 
cesses  are  combined  into  overall  system  invariants.  In 
contrast,  we  concentrate  on  a  single  process  (a  mode 
machine)  with  effects  of  other  processes  expressed  by 
the  constraints  C\  and  C*2.  After  computing  the  mode 
entry  conditions,  we  obtain  overall  system  invariants 
via  the  KEEP  operator.  Our  iterations  propagate  these 
invariants  throughout  the  system.  They  also  consider 
additional  techniques,  such  as  reaffirmed  invariants  with 
cycles,  outside  the  scope  of  our  generation  process. 

In  recent  years,  there  has  been  a  resurgence  of 
interest  in  the  automatic  generation  of  invariants  in 
conjunction  with  advances  in  automated  proof  tech¬ 
niques  [5,  7,  13,  27,  34].  These  methods  may  be  clas¬ 
sified  as  “bottom-up”  or  “top-down”  [7].  Bottom-up 
methods,  which  generate  local  program  invariants  and 
our  mode  invariants,  derive  the  invariants  automatically 
from  the  state  machine  specification.  Top-down  meth¬ 
ods  start  with  a  candidate  invariant  and  use  this  to  de¬ 
termine  an  invariant  that  is  no  weaker  (if  the  candidate 
is  indeed  invariant).  The  method  used  by  Park  et  al.  [31] 
to  generate  invariants  to  aid  in  consistency  checking  of 
RSML  [25]  specifications  is  top-down.  While  our  tech¬ 
nique  generates  only  simple  invariants,  the  generation 
of  general  safety  properties  (properties  using  temporal 
operators  that  refer  to  the  evolution  of  the  system  over 
more  than  one  state)  has  also  been  investigated  [7]. 


8  Conclusions  and  Future  Work 

This  paper  describes  how  state  invariants  can  be  auto¬ 
matically  derived  from  SCR  specifications  without  gen¬ 
erating  a  representation  of  the  complete  state  space  of 
the  system.  The  algorithm  provides  successively  better 
invariants  at  each  pass  (not  just  approximations),  so 
that  valid  invariants  are  obtained  even  if  the  algorithm 
is  not  run  to  completion. 

To  illustrate  the  utility  of  our  approach,  we  used  in¬ 
variants  derived  by  our  algorithm  to  prove  two  safety 
properties  of  the  Safety  Injection  System.  This  result 
suggests  that  our  algorithm  can  usefully  supplement 
other  techniques,  such  as  model  checking,  in  verifying 
properties  of  state  machine  models.  We  envision  a  de¬ 
velopment  environment  that  offers  many  complemen¬ 
tary  techniques — to  include  model  checking,  invariant 
generation,  and  theorem  proving.  For  some  problems, 
using  one  technique  will  be  more  cost-effective  than  us¬ 
ing  others;  for  other  problems,  two  or  more  techniques 
may  be  useful  in  concert. 

We  have  explored  a  version  of  the  algorithm  which 
does  not  require  the  boolean  encoding  of  events.  This 
algorithm  is  more  complete,  and  therefore  generates 
stronger  invariants,  but  is  considerably  less  efficient. 
We  are  also  exploring  the  extension  of  our  algorithm 
to  more  general  invariants  than  state  invariants.  More¬ 
over,  we  are  investigating  the  use  of  our  abstraction 
methods  [2,  6,  15],  which  were  originally  designed  to 
build  the  abstract  machine  XG  from  a  property  of  in¬ 
terest  q,  to  automatically  construct  the  mode  machine 
needed  to  generate  state  invariants  from  an  SCR  spec¬ 
ification. 

We  have  developed  a  prototype  tool  that  uses  our  al¬ 
gorithm  to  automatically  generate  state  invariants  from 
SCR  requirements  specifications  and  applied  it  to  the 
three  mode  transition  tables  in  an  updated  version  of 
the  A- 7  requirements  document  [1],  Together  the  ta¬ 
bles  contain  a  total  of  700  rows  and  46  modes.  In  less 
than  five  minutes,  the  tool  generated  over  20  “inter¬ 
esting”  invariants,  that  is,  invariants  not  equal  to  true, 
that  could  be  presented  to  system  users  for  validation. 
These  preliminary  results  demonstrate  the  algorithm’s 
potential  efficiency  and  practical  utility. 
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Appendix:  Proof  of  Algorithm  Correctness 

As  background  we  need  the  formal  semantics  of  the  next 
state  relation  for  E^.  From  we  first  define  the  ex¬ 
plicit  next  modes  for  two  given  states  as 

/3(s,  s')  =  {m  |  Be  :  T a{s{M),  e,  m)  A  e(s,  s')} 

We  require  the  next  state  relation  to  satisfy  the  follow¬ 
ing: 

s'(M)  £  /3(s,  s')  if /?(«,«')  ^  0 
s'(M)  =  s(M)  otherwise 

Thus  pa(s,s')  implies  that  the  mode  in  the  new  state 
is  always  taken  from  among  one  of  the  alternatives  of 
T^4  for  s(M)  having  an  event  occurrence  for  s  and  s', 
otherwise  there  is  no  change  in  the  mode  value. 

The  semantic  definitions  of  KEEP  and  NEW,  equiv¬ 
alent  to  the  respective  syntactic  forms,  are  also  useful 
in  the  proofs.  Let  each  positive  literal  be  represented 
as  ( r,true )  and  each  negative  literal  as  (r,  false).  The 
semantic  definition  of  KEEP  is  as  follows: 

KEEP(U,c)  =  {s  |  3si  :  c(si) 

A  Vr  :  ( r ,  si(r))  £  IJ  =t-  s(r)  =  si(r)}, 

where  (r,  Si(r))  £  U  means  that  either  ( r,true )  £  U  A 
si(r)  or  (r,  false)  £  U  A  -isi(r).  Intuitively,  each  si 
such  that  c(si)  holds  corresponds  directly  to  one  of  the 
disjuncts  (minterms)  of  the  standard  disjunctive  normal 
form  of  c.  For  each  such  disjunct,  if  the  literal  appears 
in  that  disjunct  and  is  found  in  U — i.e. ,  (r,  Si(r))  £  U — 
then  we  “keep”  it  (s(r)  =  si(r));  otherwise,  we  replace 
it  by  true  (which  is  equivalent  to  s(r)  =  true  V  s(r)  = 
false  in  the  final  result).  The  semantic  definition  of 
NEW  is  similar: 

NEW{q)  =  {s'  |  31  :  </(s,s')} 

Several  lemmas  will  be  useful  in  the  proof  that  our 
algorithm  computes  mode  invariants.  First,  we  prove 
some  properties  of  the  KEEP  and  NEW  operators: 

Lemma  1(1)  e(s,s')  =>  NEW(e)(s'),  (2)  c  <  d  im¬ 
plies  KEEP(U,c)  <  KEEP(U,d),  (3)  IJ  C  V  implies 
KEEP(V,  c)  <  KEEP(IJ,  c),  and  (/,)  c  <  KEEP(U,c). 

Proof: 

The  proofs  of  these  four  properties  are  simple  applica¬ 
tions  of  the  semantic  definitions  of  NEW  and  KEEP. 
For  example,  (1)  requires  that  we  prove  e(s,s')  => 
3si  :  e(«i,  s').  To  complete  the  proof  we  simply  choose 
«i  =  s.  ■ 

Next,  we  prove  some  properties  of  the  invariant  gener¬ 
ation  operators: 


Lemma  2  (1)  Pi(m)  <  Pi-i(m),  (2)  Xi(m )  C 
Xi+1(m),  and  (3)  Ni+1(m)  <  N^m). 

Proof:  By  induction  on  the  number  of  passes  i. 

(i)  P1(m)  =  KEEP{Xi(m),Ni(m))  A  C\  <  C\  = 
Po(m).  Using  this  result  it  is  easy  to  show  that 
Xi(m)  C  X’i (m)  and  N^m)  <  Ni(m). 

(ii)  Assume  the  claim  is  true  for  i  =  k.  Parts  (2)  and 
(3)  of  the  induction  hypothesis  and  parts  (2)  and  (3)  of 
Lemma  1  imply  Pk+i  =  KEEP^Xh+i^m),  Atj,+1(m))  < 
KEEP(Xk+1(m),Nk(m))  <  KEEP(Xk(m),  Nk(m))  = 
Pk(m).  From  Pk+ 1  <  Pk,  it  follows  immediately  that 
Xk+i (m)  C  Xk+2(m)  and  Nk+2(m)  <  Nk+1(m).  U 

The  next  lemma  says  basically  that  if  the  mode  does 
not  change  when  there  is  no  [3  transition  possible,  then 
KEEP(Xi,  c )  remains  true: 

Lemma  3  If  we  let  m  =  s(M)  =  s'(M), 

l3(.s,s')  =  0,  C2(s,  s')>  Pi-i(m)(.s),  P^_l(m)(s,),  and 
KEEP(Xi,c)(s),  then  KEEP(Xi,  c)(s') 

Proof:  By  contradiction. 

Assume  that  -> KEEP(Xi,c)(fs').  Then  there  must  be 
some  term  t  of  KEEP(Xi,  c)  and  some  literal  l  of  t  such 
that  £(s)  yet  -> £(s').  We  must  have  £  £  Xi(m).  By  the 
definition  of  Xi,  @F(f)  A  Pi-i(m)  A  Pi-i(m)'  A  C2  => 
EX(m).  Thus  from  the  hypotheses  and  the  assump¬ 
tion  we  have  EX(m)(s,  s').  By  the  definition  of  EX  we 
have  that  there  exists  e  and  m'  with  (m,e,mr)  and 
e(s,s').  Finally  this  gives  m'  £  l3(s,s')  in  contradiction 
to  a  hypothesis.  ■ 

In  our  setting,  for  each  m  the  formula  M  =  m  => 
Pi(m)  is  a  mode  invariant  if  and  only  if  for  all  reach¬ 
able  states  s  of  E^,  Pi(s(M))(s).  It  is  sufficient  for  our 
purposes  to  prove  correctness  of  the  generation  algo¬ 
rithm  using  an  analog  of  the  Basic  Rule  of  Manna  and 
Pnueli  [28].  We  say  that  a  mode  invariant  is  a  basic 
mode  invariant  if  it  can  be  proved  using  this  rule: 

B  asic  Mode  Invariance  Rule:  To  show 
M  =  m  =>  Pi(m)  is  a  mode  invari¬ 
ant  for  all  m  it  is  sufficient  to  show  (i) 

Vto  :  ^(m)  =>  Pi(m),  and  (ii)  Vs,  s'  : 
Pi(s(M))(s)  A  Pa(s,  s')  =>  Pi(s' (M))(s') 

Lemma  4  If  M  =  m  =>  _P8_i(m)  is  a  basic  mode  in¬ 
variant  for  all  m  then  M  =  m  =>  Pi(m)  is  a  basic  mode 
invariant  for  each  m. 

Proof:  By  the  Basic  Mode  Invariance  Rule. 

(i)  8A(m)  =>  Ni(m)  via  the  of  the  initial  states  case  for 
the  definition  of  Ni(m).  By  Lemma  1  part  (4)  ^(m)  => 
KEEP(Xi(m),  Ni(m)).  Finally  using  the  axiom  C\  and 
the  definition  of  Pi  we  have  ^^(m)  =>  Pi(m). 


(ii)  Assume  that  Pi(m)(s)  and  pa(s,s')  where  m  = 
s(M)  and  m!  =  By  Lemma  2  part  (1) 

Pi-i(m)(s).  The  given  basic  mode  invariance  also 
means  that  Pi-i(m')(fsr)  holds.  There  are  now  two  cases 
to  consider  from  the  assumption  about  pa'- 

m'  G  l3(s,s')  :  In  this  case  there  exists  e  with 
T A(m,  e,  m')  and  e(s,s').  Lemma  1  part  (1)  gives 
NEW(Pi-i(m)  A  C'j  A  e)(s')  so  Nj(m')(s'),  and  by 
Lemma  1  part  (4)  KEEP(Xi(m'),  Ni(m'))(s'). 

m'  =  m  and  /3(s,s')  =  0  :  KEEP(Xi(m'), 
follows  from  Lemma  3. 

Finally,  applying  axiom  C\  and  the  definition  of  Pi,  we 
have  Pi(mr)(sr).  ■ 

Theorem  2  M  =  m  =>  Pi(m)  is  a  basic  mode  invari¬ 
ant  for  T,a  for  each  m  and  each  pass  i.  Furthermore, 
( M  =  m  =>  Pi(m))  <  ( M  =  m  =>  Pi-i(m)),  with  at 
least  one  invariant  strengthened  on  each  pass  i  before 
the  fixpomt  is  reached. 

Proof: 

The  first  part  is  an  induction:  (i)  M  =  m  =>  Po(m)  is 
clearly  a  basic  mode  invariant,  (ii)  The  induction  step 
follows  immediately  from  Lemma  4.  The  second  part 
follows  from  Lemma  2  part  (1).  ■ 


